48 Annual Review 2012

In conjunction with PODC 2012, the TransForm project (Marie Curie Initial Training Net-work) and EuroTM (COST Action IC1001) supported the 4th edition of the Workshop on theTheory of Transactional Memory (WTTM 2012). The objective of WTTM was to discuss newtheoretical challenges and recent achievements in the area of transactional computing. Theworkshop took place on July 19, 2012, in Madeira, Portugal.This year’s WTTM was a milestone event for two reasons. First, because the same year, thetwo seminal articles on hardware and software transactional memories [15, 21] were recognized asoutstanding papers on principles of distributed computing, whose significance and impact on thetheory and practice of distributed computing have been evident for at least a decade. Second,the winners of this prestigious ACM/EATCS Edsger W. Dijkstra Prize, Maurice Herlihy, EliotMoss, Nir Shavit and Dan Touitou, were present at the workshop and three of them discussedtheir current progress with other outstanding researchers from the field. This report is intendedto give highlights of the problems discussed during the workshop. Transactional memory is a concurrency control mechanism for synchronizing concurrent ac-cesses to shared memory by different threads. It has been proposed as an alternative to lock-basedsynchronization to simplify concurrent programming while exhibiting good performance. The se-quential code is encapsulated in transactions, which are sequences of accesses to shared or localvariables that should be executed atomically by a single thread. A transaction ends either by com-mitting, in which case all of its updates take effect, or by aborting, in which case, all its updatesare discarded and never become visible to other transactions. 1 Consistency criteria Since the introduction of the transactional memory paradigm, several consistency criteria havebeing proposed to capture its correct behavior. Some consistency criteria have been inherited from ACM SIGACT News116December 2012 Vol. 43, No. 4 the database field (e.g., serializability, strict serializability), others have been proposed to extendthese latter to take into account aborted transactions, e.g., opacity, virtual world consistency; someothers have been proposed to define the correct behavior when transactions have to be synchronizedwith non transactional code, e.g., strong atomicity.Among all the criteria, opacity, originally proposed by Guerraoui and Kapalka [13], gained alot of attention. In his first talk, Srivatsan Ravi showed that in any safe restriction of opacity, notransaction may read from a transaction that has not invoked tryCommit. He presented a definitionof opacity that intuitively captures this feature and showed that it is a safety property in the formalsense, i.e., it is prefix-closed and limit-closed. This is a joint work with Hagit Attiya, Sandeep Hansand Petr Kuznetsov.Victor Luchangco presented his joint work with Mohsen Lesani and Mark Moir provocativelytitled “Putting opacity in its place” in which he presented the TMS1 and TMS2 consistency con-ditions and clarified their relationship with the prefix-closed definition of opacity. Broadly, theseconditions ensure that no transaction observes the partial effects of any other transaction in anyexecution of the STM without having to force a total-order on transactions that participate in theexecution. In particular, TMS1 is defined for any object with a well-defined sequential specificationwhile TMS2 is specific for read-write registers. They further show using IO Automata [18] thatevery behavior allowed by TMS2 is allowed by TMS1 and formally prove that the NOrec algorithmsatisfies TMS2. Moreover, algorithms that satisfy opacity also satisfy TMS1, and algorithms thatsatisfy TMS2 also satisfy opacity.While opacity defines the correctness of transactional memories when shared variables are ac-cessed only inside transactions, understanding the interaction between transactions and locks orbetween accesses to shared variables in and outside transactions has been a major question. This ismotivated by the fact that the code written to work in a transactional system may need to interactwith legacy code where locks have been used for synchronization. It has been shown that replacinga lock with a transaction does not always ensure the same behavior.Srivatsan Ravi presented his joint work with Vincent Gramoli and Petr Kuznetsov on the locally-serializable linearizability (ls-linearizability) consistency criterion that applies to both transaction-based and lock-based programs, thus allowing to compare the amount of concurrency of a concurrentprogram [10]. In short, this consistency criterion captures the correctness of high-level data types(linearizability) with the correctness of their low-level implementations (thread-safety) by guaran-teeing that the sequence of sequential events corresponding to each high-level operation is consistentwith “some” sequential execution.Stephan Diestelhorst presented his preliminary work with Martin Pohlack, “Safely AccessingTimestamps in Transactions”. He presented scenarios in which the access to the CPU timestampcounter inside transactions could lead to unexpected behaviors. In particular, this counter is nota transactional variable, so reading it inside a transaction can lead to a violation of the single lockatomicity semantics: multiple accesses to this counter within transactions may lead to a differentresult than multiple accesses within a critical section. In this talk, a solution to prevent severaltransactions from accessing the timestamp concurrently was also sketched.Annette Bienusa presented the definition of snapshot trace to simplify the reasoning on thecorrectness of TMs that ensure snapshot isolation. This is a joint work with Peter Thiemann [5].Finally, Faith Ellen stated that despite the fact that a rich set of consistency criteria have beenproposed there is no agreement on the way the semantics of a transactional memory has to bedefined: operationally [14], as a set of executions [13, 22], or using automata [7]. ACM SIGACT News117December 2012 Vol. 43, No. 4 2 Data structures for transactional computing Eliot Moss’ talk intended to explore how the availability of transactions as a programming constructmight impact the design of data types. He gave multiple examples on how to design data typeshaving in mind that these types are going to be used in transactions.In a similar direction, Maurice Herlihy considered data types that support high-level methodsand their inverse. As an example a set of elements supports the method to add an element, add(x),and the method to remove an element from the set remove(x). For these kind of data types, he dis-cussed the possibility to apply a technique called transactional boosting which provides a modularway to make highly concurrent thread-safe data structures transactional. He suggested to distin-guish the transaction-level synchronization with the thread-level synchronization. In particular, tosynchronize the access to a linearizable object, non-commutative method calls have to be executedserially (e.g., add(x) and remove(x)). Two method calls are commutative if they can be applied inany order and the final state of the object does not change. For example, add(x) and remove(x)do not commute, while add(x) and add(y) commute. Since methods have inverses, recovery can bedone at the granularity of methods. This technique exploits the object semantics to synchronizeconcurrent accesses to the object. This is expected to be more efficient than STM implementationswhere consistency is guaranteed by detecting read/write conflicts.